home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16521 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.7 KB
  1. Path: news.nyu.edu!schonberg!dewar
  2. From: dewar@cs.nyu.edu (Robert Dewar)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 10 Apr 1996 21:22:25 -0400
  6. Organization: Courant Institute of Mathematical Sciences
  7. Message-ID: <dewar.829185159@schonberg>
  8. References: <dewar.828936837@schonberg> <828964950snz@genesis.demon.co.uk> <dewar.828987544@schonberg> <4kb2j8$an0@solutions.solon.com> <4kbrt5$k3h@mulga.cs.mu.OZ.AU> <DpnxAF.6xq@eskimo.com>
  9. NNTP-Posting-Host: schonberg.cs.nyu.edu
  10. X-Newsreader: NN version 6.5.0 (NOV)
  11.  
  12. Steve said/asked
  13.  
  14. >Perhaps the essence of the debate is getting lost in the shouting.
  15. >An example was brought up which, I gather, boils down to
  16. >
  17. >        char buf[100];
  18. >        /* exactly 68 characters are known to be available on fd */
  19. >        read(fd, buf, 1000);
  20. >
  21. >It wasn't clear whether this was being presented as a real-world
  22. >example of a portability problem, or as an example of code that
  23. >someone thinks should be written, should be portable in practice,
  24. >and should work.  (I sincerely hope it's the former, and Robert
  25. >Dewar has assured me that he, for one, is not defending it.)
  26.  
  27. Of course it is being brought up as an example of a portability problem.
  28. As for
  29.  
  30.   (a) should be written
  31.   (b) should be portable in practice
  32.   (c) should work
  33.  
  34. I would say, historically, (b) and (c), but not necessarily (a). If the
  35. spec of the POSIX read were defined to say "the buffer must be at least
  36. as long as the data that is read", then certainly (b) and (c) would be
  37. true. As for (a), note that of course *no one* would explicitly write
  38. the dubious code, it occurs in the context of a loop, something like
  39.  
  40.    while (p < endbuf) {read(fd, p, 8192); p+=8192;)
  41.  
  42. where the precondition is that the data read from fd is known not to
  43. go "past" endbuf. Of course it is possible to modify this code so that
  44. the last read does not have an excessive count, but the resulting code
  45. is a little more complex.
  46.  
  47. The issue is not whether this code is defensible or not. Clearly this was
  48. in fact a significant bug, since the code broke on Linux, and this was
  49. intended to be portable, so it was wrong, caused trouble, and had to be
  50. fixed. In that sense it was certainly wrong!
  51.  
  52. However, given the vague definition of read, it is easy to see how the
  53. coder here in fact assumed that (b) and (c) were true, and hence the
  54. bug arose.
  55.  
  56. If the spec of read had said: "the buffer must be at least the length
  57. given by the third parameter, even if the actual data is smaller", then
  58. of course the error would not have been made in the first place. And that,
  59. all along has been my point. Careful specification of interfaces, and
  60. accurate knowledge of these specifications, can definitely improve
  61. portability.
  62.  
  63.